Automation controllers are typically connected to industrial equipment such as assembly lines, machine tools and processing equipment to operate the equipment in accordance with a stored program. In controllers such as those disclosed in the above cited patents, for example, the control program is stored in a memory and includes instructions which are read out in rapid sequence and executed to examine the condition of selected sensing devices on the controlled equipment, or to energize or de-energize selected operating devices on the controlled equipment contingent upon the status of one or more of the examined sensing devices.
Large controllers consist of a number of modules with different functions assigned to each module. For example, one module may execute the user control program, another may interface the controller to the remote sensing and operating devices, and yet another module may control communications with a host computer via a local area network. The modules are typically housed in a rack and are interconnected by a bus structure on the backplane of the rack.
Since the backplane buses are needed by all the modules, it is necessary to establish procedures for sharing the common buses. In one approach described in U.S. Pat. Nos. 4,691,296 and 5,038,317, for example, one of the modules serves as a "master" of the backplane buses and it scans, or polls, all of the other "slave" modules on the backplane to determine if they have data to exchange. In a variation of this technique described in U.S. Pat. No. 3,815,099, the master module may be interrupted by requests from slave modules that require prompt access to the backplane buses. The master module has a circuit for receiving the interrupt requests and granting access to requesting modules based on a priority scheme. Such interrupt schemes enable occasional high priority data exchanges to occur promptly while the scanning, or polling, process is conducted in the background on a continuous basis. This approach works well when there is a single module that dominates the backplane buses, but it is less appropriate when more than one module needs control of a substantial portion of the bus bandwidth.
Another approach exemplified by the controllers described in U.S. Pat. Nos. 4,442,504 and 4,876,664 enables any module connected to the backplane bus to become master for the purpose of exchanging data with another module. In these controllers one of the modules contains an arbitration circuit that grants access to requesting modules according to a fixed priority scheme. In one method, priority of access is granted to the modules according to the physical location of requesting modules in the backplane rack and this preference does not change from one arbitration period to the next. In the other method, priority is determined by position in the backplane rack, but the order is rotated in a methodical manner during successive arbitration periods such that all modules are guaranteed priority access on a regular basis.
Prior bus arbitration methods have a number of limitations when employed in industrial applications. In some systems arbitration for access to the backplane bus is performed by one module, and if that module is removed or fails, the entire backplane rack is rendered inoperable. More importantly, however, the single phase arbitration methods used in most prior systems do not recognize differences in the priority of the data to be exchanged. That is, priority is granted simply on the basis of the module requesting bus access during that arbitration period, and no consideration is given to the type of data to be exchanged. As a result, standard bus architectures such as VMEbus, MULTIBUS I and MULTIBUS II are severely limited in industrial applications. For example, an analog input module may produce normal data on a relatively infrequent basis (e.g. seconds), and as a result, that module may be given a low priority under one of the prior arbitration schemes. However, that module may also report alarm conditions which should be given high priority. Conversely, a module which connects the backplane to a serial I/O network will be given high priority under prior arbitration schemes because it conveys I/O data that must be reported within milliseconds of events. However, such modules may also convey large blocks of data from I/O devices that report infrequently, and will monopolize the bus during those infrequent intervals if given the same high priority level. In other words, many modules connected to an industrial backplane will transfer data that is highly time critical and should, therefore, be given a high priority, and such modules may also transfer large amounts of data that is not time critical and should be given a low priority.
Another limitation of standard buses such as Futurebus+ is the high cost to implement their protocols. This is due to the large number of backplane lines required to convey the various control and status signals between modules (see e.g. IEEE standard 896.1, 1991, page 48 and FIG. 15). These many backplane lines must be driven by each module and the signals on them must be received by circuitry in each module. With highly functional, expensive modules, such as processor modules, the cost of extensive backplane interface circuitry for arbitration is not burdensome. However, with low cost input and output modules, complex backplane interface circuitry cannot be cost justified and therefore a need exists to reduce the number backplane lines required for arbitration.
Also, the mix of modules in an industrial automation controller typically have different performance and communication requirements. For example, high cost/complexity modules may have wide (i.e. 32 or 64 bit) internal architectures and communication interfaces to achieve a high throughput, while inexpensive, low complexity modules require far less capability. However, since all of the modules must interoperate on a backplane bus within the industrial controller, all of the modules in the past had to be designed to the same standards, i.e. the highest capability demanded by the most complex modules. Consequently, even the lowest complexity modules had to support wide communications interfaces to the bus, which required far more line receivers, line drivers, buffers, etc. than were necessary, and thus increased their cost substantially. Therefore, a need exists for a capability to permit interoperability of modules with a wide range of different operational requirements on a single, common bus structure.
Another consideration in current industrial control systems is the flow of message traffic between modules. Often, a module may be overwhelmed when messages are received faster than they can be processed. When a message can not be accepted, some form of negative acknowledgement (NACK) is sent back to the transmitting module, but not until most or all of the message has already been sent. Further, in order to prevent such overflow situations, the modules had to be designed with additional resources in terms of memory for control blocks, buffers, etc. to better accommodate peak message traffic. Of course, this also increases the cost of the modules, particularly in otherwise low cost/complexity modules. Thus, a need also exists for a means to control the flow of messages between modules, so that modules may effectively use a limited amount of resources while at the same time reducing the time spent transmitting and retransmitting rejected messages.